Wireless and wireline communications networks have evolved to encompass a variety of services, switching platforms, applications, data processing system hardware and equipment that are collectively referred to as network products. Before deploying such network products within a live network environment, it is important to first test these network products to ensure that their operation is as expected. Typical telecommunications environments rely upon network elements (e.g., packet switches, database nodes, routers, etc.) produced by a variety of manufacturers, and such network elements may each further include a number of operating system or application software revisions. Consequently, one of the primary objectives or goals of the testing process prior to deployment is to identify and resolve any potential problems in the provisioning of network services that may result from the diverse nature of the collection of network elements. Such problems may include, for example, compatibility problems between newly developed network elements and existing or legacy equipment/software.
A complete test regimen may involve multiple test platforms that are required to perform several tests in parallel on several switches, with a variety of resources being required to perform each test. For example, test platforms may require connections to several switches in order to send commands corresponding to a test, and to subsequently collect results of the test. From an operational standpoint, providing a dedicated connection from each test platform to each switch is typically not practical due to the large number of dedicated connections that would be involved. Furthermore, a particular test platform may not be capable of being physically connected to multiple switches at the same time.
As an alternative to simultaneous permanent connections, a temporary connection may be manually established from a test platform to a device under test (DUT) when the test platform needs to communicate with a test program executing on the DUT. However, such manual connection techniques are time consuming and inefficient, and consequently are often deemed unacceptable by network operators.
With particular regard to test platforms, it will be appreciated that such equipment can be driven by a data processing system software application that communicates with the DUT via commands over a serial connection. A problem with such test devices is that they typically require a command line interface dedicated to accomplishing a narrowly defined test objective and is therefore both cumbersome and time consuming to use. Scripted batch files that automate a series of commands from a test platform to the DUT can be used to alleviate this problem, as the use of batch files does not require manual entry of commands to the connected test device. Consequently, a single batch file, or small set of batch files, which contains all the commands necessary to accomplish a particular test objective may be employed to execute a complicated sequence of test instructions, thereby freeing the test operator to perform other tasks for duration of the test sequence. However, batch files must still be written using device-specific instructions and require that the operator have detailed knowledge of the command line interface commands of each device being tested.
FIG. 1 is a schematic diagram illustrating a conventional architecture associated with the testing of a telecommunications packet switch. FIG. 1 includes a test architecture, generally indicated by reference numeral 100, that is comprised of a test management platform (TMS) 110, a signal transfer point (STP) 112, a manually-operated STP administrative interface 114, a network test message generator/monitoring node 116 (e.g., the Tekelec MGTS™ testing and monitoring product), and a manually-operated administrative interface 118. It will be appreciated that STP 112 and MGTS™ 116 are directly connected via dedicated signaling system 7 (SS7) signaling links 120. MGTS™ 116 generates SS7 signaling message traffic and simulates SS7 signaling nodes that could be connected to STP 112 in a real network. TMS 110 and the two administrative interface terminals 114 and 118 are connected to STP 112 and MGTS 116 nodes via RS-232 links. More particularly, STP administrative terminal 114 and MGTS™ administrative terminal 118 are connected to the command line interfaces of STP 112 and MGTS 116, respectively. TMS 110 is also connected to the command line interfaces of both STP 112 and MGTS 116.
As such, it will be appreciated that a complex test scenario could involve a large degree of operator intervention and subsequent manual configuration of the two devices under test. For instance, a particular test of STP 112 may require that MGTS™ 116 attempt to bring one of the plurality of SS7 communication links 120 into service. Execution of this portion of the test can be initiated by TMS 110 via one or more commands that are sent to the MGTS node via the TMS-to-MGTS™ command line interface connection. A particular test scenario being executed by the TMS 110 could require a dynamic or decision-tree-type response on the part of the TMS (i.e., selection of the next test is dependent on the result of the preceding test). For instance, TMS 110 may be required to perform a second test, TestCase_AlignedTrue if the particular SS7 signaling link in question was successfully aligned. If the signaling link in question was not successfully aligned, TMS 110 may be required to perform a third test, TestCase_AlignedFalse. As such, a human operator is required to observe the results of the first test via the MGTS™ administrative terminal 118, and provide feedback to TMS 110. Such manual feedback is human-resource-intensive, inefficient and prone to operator error.
With regard to overall test tool evolution, the incorporation of graphical user interface (GUI) based enhancements to testing systems have been instrumental in making the testing process more intuitive and user-friendly. However, such enhancements have not focused on the human operator-intensive elements of the testing process, such as reducing the need for device-specific commands and different terminals connected to each device being tested.
Local area network (LAN) technology and communication architectures have also enhanced the testing of network products. GUIs are conveniently located, either locally or remotely, to a particular data processing system that drives the actual testing of network products. Client/server technology is utilized to provide remote access to test systems. A client application includes a GUI that allows a user to access a remote test system. A server application receives and processes requests from the client. The server also executes on a system in the network. The client/server framework allows a client to be located on any system in the network, even on the same system on which the server resides.
With the many varieties of network products and methodologies for testing of network products currently available, test devices must be proficient in testing a large number of applications and executing the many varieties of test cases associated with those applications. Thus, a test device must be capable of learning or adapting to new test case formats and new test interfaces as required.
A test case defines how a particular test will be performed. For example, a test case may simply be a batch file containing instructions for performing a test, or a test case may be a file of commands or directives administered through a GUI. Additionally, a test case may include a data structure stored in memory that is built by a data processing system upon receipt of instructions from a client or other application. Regardless of how a test case is implemented the, a test case embodies the action which will take place in order to perform a test.
From an operational perspective, there exists a need for the capability for users in a network environment to share test cases and test case results for multiple devices under test in a test network environment. There also exists the need for a testing system that performs any type of test case without knowing the specific test case formats and methodologies of each and every test case available for execution on a test network.
Additionally, there exists a need for the capability of designating the test functions to be tested as a sequence of interrelated, cross-communicated test functions. As discussed briefly above with regard to the example shown in FIG. 1, values produced as output by a first DUT may be used as input by a second DUT. However, as indicated above, using the results from one test case as input to another test case requires manual intervention by an operator with detailed knowledge of device-specific test case commands. Accordingly, there exists a long-felt need for methods and systems for testing communications network components that reduce the need for operator intervention and knowledge of device-specific test commands.